Composable 本身是抽象化工具，但當抽象層不斷增加時，這些抽象是否也會形成 Runtime Cost？

前幾天的 VDOM Stress Test 已經驗證了大量 UI Rendering 的成本分布。

這一輪換個角度，從 Composable 數量與 Reactive Graph 開始。

實際專案裡，一個 Composable 往往還會再呼叫其他 Composable，當這種層級持續增加，Reactive dependency 也會跟著變複雜。

因此這次要驗證的問題是 Composable Depth 增加後，Reactive Work 會增加多少？這些額外工作最後是否反映在 Vue Runtime Cost？

今天先建立固定的實驗環境，明後天再分別跑 Vue 3.5.40 與 Vue 3.6.0-rc.2。

先把變數控制住

這次唯一改變的變數是：

Composable Depth
1 → 5 → 10 → 20

例如 Depth 5：

useLayer5()
    ↓
useLayer4()
    ↓
useLayer3()
    ↓
useLayer2()
    ↓
useLayer1()

其他條件全部固定：

Component Tree   Fixed
DOM              Fixed
Data             Fixed
Update Action    Fixed
Browser          Fixed
Vue Version      Fixed

Composable Depth Variable

UI 因此刻意保持非常簡單：

<template>
  <div>
    <div>{{ value }}</div>

    <button @click="triggerUpdate">
      Update
    </button>
  </div>
</template>

這樣可以把大量 DOM、Layout、Paint 等因素壓到最低，讓實驗更容易觀察 Reactive Work。

Build Phase：建立 Reactive Graph

最底層先建立 state：

function useLayer1() {
  const value = ref(0)

  return { value }
}

下一層再建立 computed dependency：

function useLayer2() {
  const layer1 = useLayer1()

  const value = computed(() => {
    return layer1.value.value * 2
  })

  return { value }
}

再往上逐層組合，形成不同 Depth：

因此 Build Duration 是混合成本，它同時包含 Composable 執行、Reactive object 建立、computed 建立與初始 Render，不能直接拿來代表某一個 Composable function 的成本。

這也是為什麼後續會把 Build 與 Update 分開量測。

Update Phase：只操作已建立的 Graph

完成 Mount 後，不再重新建立 Composable，每次只做相同的 Update：

state.value++

await nextTick()

此時主要觀察的是已經存在的 Reactive Graph：

Chain 建立完成後，不再重新呼叫 Composable，只修改既有 state，等待 Reactive Update 完成後量測。

這個階段更接近 Reactive Graph 已經建立後，Depth 增加會讓一次 Update 多做多少工作？

Metrics：不要只看一個 Duration

這次至少分成三層觀察。

1. Reactive Work

先確認 Scenario 本身真的隨 Depth 增加：

Composable Instance
Computed
Watch
WatchEffect

例如：

這層回答的是：Scenario 到底增加了多少 Reactive Work？

2. Vue Runtime Cost

再觀察：

Mount Duration
Update Duration

其中 Update 是這次比較重要的指標，如果 Depth 從 1 增加到 20，而 Reactive Work 明顯增加，接著 Update Duration 也呈現穩定增加，才值得進一步追 Runtime Attribution。

3. Browser Cost

沿用前幾天建立的 CDP Trace：

Scripting
Rendering
Painting

目的是確認 Duration 的增加究竟落在哪一層。

Composable Depth
       ↓
Reactive Work
       ↓
Runtime Cost
       ↓
Scripting / Rendering / Painting

例如：

Depth       ↑
Computed    ↑
Update      ↑
Scripting   ↑
Rendering   →
Painting    →

這時才有足夠證據繼續追查 Reactive Work 與 Runtime Cost 的關係。如果變成：

Depth       ↑
Computed    ↑
Update      →

就只能說 Reactive Graph 變複雜，現有測量沒有顯示明顯的 Runtime Duration 增加。

Scenario 建立完成

因此今天建立的 Scenario 命名為 Composable Chaos ，目錄保持簡單：

📂 src/scenarios/composable-chaos/
├── 📄 ComposableChaosPage.vue
└── 📄 README.md

整個 Validation Flow 沿用前面 VDOM Stress Test 的量測架構：

Composable Scenario
        ↓
CDP Trace
        ↓
Metrics
        ↓
Runtime Attribution
        ↓
Evidence

明天固定 Scenario，只切換到 Vue 3.5.40 建立 Baseline，後天再切換 Vue 3.6.0-rc.2。

到時候才能回答 相同的 Composable Expansion，在 Vue 3.6 中是否真的降低了 Vue Runtime Cost？

如果改善出現在 Runtime，才繼續往 Framework 層追。

如果 Reactive Work 增加，但 Runtime Cost 沒有明顯變化，問題就要回到 Architecture 與 Reactive Graph 的設計。

GitHub Repo.

• src/scenarios/composable-chaos